โ RNS 1.4.2 released https://pypi.org/project/rns/
๐ฌค rns.recipes
top
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โLXMF 1.1.0: Missing propagation-peer path causes synchronization attempts every 24 seconds without backoff โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Started by nilu96 ยท 12d ago
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-1
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ nilu96 #1 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 12d ago
Iโm seeing repeated path requests from lxmd for an unreachable LXMF propagation peer. The
requests occur exactly every 24 seconds.
The scenario is:
โข lxmd connects to rnsd through the local shared instance.
โข The peer still has one or more unhandled_messages.
โข No path exists to the peer.
LXMFโs job loop runs every four seconds and calls sync_peers() every sixth iteration,
producing the observed 24-second interval. During each attempt, LXMPeer.sync():
1. Finds that no path exists.
2. Calls RNS.Transport.request_path().
3. Waits 7.5 seconds.
4. Finds that there is still no path and returns, saying it will retry later.
However, this missing-path branch does not appear to:
โข increment sync_backoff;
โข set next_sync_attempt;
โข mark the peer unreachable; or
โข otherwise make the peer temporarily ineligible for synchronization.
Consequently, the peer remains alive, idle and immediately eligible during the next
24-second scheduler pass.
LXMF already implements an incremental backoff of approximately 12 minutes per failure,
but it seems to be activated only after a path exists and link establishment begins. A
failed path lookup never reaches that logic.
RNS appears to be behaving correctly. It receives the request from the local lxmd
shared-instance client, assigns a new request tag, and forwards the request through the
other interfaces. In a transport-enabled instance, the RNS transport identity is shown as
the immediate requester, although lxmd is the application-level initiator.
Would it be intended for an unreachable propagation peer with pending messages to
generate a new path request every few seconds indefinitely, or is this a retry-policy
gap?
My expectation would be that an unanswered path lookup counts as a synchronization
failure and activates a bounded backoffโfor example:
request path
wait for path timeout
if no path:
mark peer unreachable
increment backoff
set next synchronization attempt
return
A later announce, discovered path or successful link could reset the backoff.
โ 4 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-2
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Mark #2 โ
โ bc7291552be7a58f โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 11d ago
That's definitely an oversight. Fixed in
c939e253614d63601240456032e972bd3ab347f2 .
โ 6 โ 0 โค 2
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-3
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ nilu96 #3 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 11d ago
Thanks a lot, that was quick!
โ 0 โ 0 โค 0
โ INFO โ Identify to this node to post. How?
bottom